This review was generated by Claude Code, an AI assistant, on behalf of @gnodet.

This is a well-crafted SPI addition. The implementation is clean and the test coverage is thorough. Approving with a few minor suggestions below.

What works well

• Lock discipline: Notifications fire outside the ReentrantLock, so listeners can safely re-read the registry (e.g., call getTools()) without deadlocking. This is documented in the AiToolRegistryListener Javadoc.
• Error isolation: A throwing listener is caught and logged without affecting the registration itself or other listeners. This is verified by testListenerExceptionDoesNotBreakRegistrationOrOtherListeners.
• Idempotent no-ops: Re-adding the same spec instance fires no duplicate event; removing an absent spec fires nothing. Both are tested.
• Test quality: Tests follow all Camel conventions -- package-private classes, AssertJ, no Thread.sleep(), no JUnit public. The lifecycle test uses CopyOnWriteArrayList for thread safety while the unit test correctly uses plain ArrayList.
• @since 4.22 on the new AiToolRegistryListener interface.

Minor suggestions

1. removeListener missing Javadoc — For consistency with addListener (which has a doc block), consider adding a brief Javadoc comment, e.g.:

   /**
    * Removes a previously added listener. No-op if the listener was not registered.
    */
   public void removeListener(AiToolRegistryListener listener) {

2. No null guard on addListener — If null is passed, CopyOnWriteArrayList accepts it silently. Later, during notification, listener.toolRegistered(...) throws NPE which is caught and logged as a generic warning — making the root cause hard to diagnose. An early Objects.requireNonNull would fail fast:

   public void addListener(AiToolRegistryListener listener) {
       Objects.requireNonNull(listener, "listener");
       listeners.add(listener);
   }

3. Concurrency ordering caveat — Since notifications fire outside the lock, two concurrent threads performing put and remove on the same spec could theoretically deliver deregistered before registered. In practice Camel route lifecycle is sequential per route, so this is unlikely. But since the Javadoc already documents the "subscribe-then-snapshot" idiom (showing attention to concurrency semantics), consider adding a note: "Notification ordering is guaranteed within a single thread but not across concurrent threads."

All minor — none are blockers. Nice work!